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Uberblick. Eine reine Peer-to-Peer-Version eines elektronischen 
Zahlungsverfahrens wiirde es ermoglichen, dass Online-Zahlungen von einer Partei 
direkt an eine andere gesendet werden, ohne iiber ein Finanzinstitut zu gehen. 
Digitale Signaturen bilden einen Teil der Losung, aber die Hauptvorteile gehen 
verloren, wenn weiterhin eine vertrauenswiirdige dritte Partei notwendig ist, um 
Double Spending (Mehrfachausgaben) zu verhindern. Wir schlagen eine Losung 
fur das Double-Spending-Problem vor, indem wir ein Peer-to-Peer-Netzwerk 
benutzen. Das Netzwerk gibt Transaktionen einen Zeitstempel, indem es sie in eine 
fortlaufende Kette von Hash-basierten Arbeitsbeweisen (Proof-of-Work) hasht und 
so eine Aufzeichnung erzeugt, die nicht geandert werden kann, ohne den Proof-of- 
Work neu zu erzeugen. Die langste Kette dient nicht nur als Nachweis fur die 
Sequenz bezeugter Ereignisse, sondem auch als Beweis, dass sie vom groBten Pool 
an CPU-Leistung stammt. Solange der GroBteil der CPU-Leistung von Nodes 
kontrolliert wird, die nicht kooperieren, um das Netzwerk anzugreifen, werden 
diese die langste Kette generieren und schneller sein als die Angreifer. Das 
Netzwerk selbst erfordert nur eine Minimalstruktur. Nachrichten werden auf 
Best-Effort-Basis iibertragen und die Nodes konnen das Netzwerk beliebig 
verlassen und wieder betreten, da sie die langste Proof-of-Work-Kette als Beweis 
dariiber akzeptieren, was geschah, wahrend sie weg waren. 


1. Einfuhrung 

Es hat sich ergeben, dass der Handel irn Internet inzwischen fast vollstandig darauf beruht, dass Finanzinstitute 
als zu vertrauende dritte Parteien dienen, um elektronische Zahlungen zu verarbeiten. Wahrend dieses System fur 
die meisten Transaktionen ausreichend gut funktioniert, leidet es nach wie vor unter den Schwachen eines 
Modells, das auf Vertrauen beruht. Vollstandig unumkehrbare Transaktionen sind nicht wirklich moglich, da 
Finanzinstitute es nicht vermeiden konnen, in Streitfallen zu vermitteln. Die Kosten der Vermittlung erhohen die 
Kosten der Transaktion, was die MindestgroBe fur machbare Transaktionen erhoht und die Moglichkeit kleiner 
Gelegenheitstransaktionen eliminiert. Ein groBerer Schaden entsteht dariiber hinaus durch den Wegfall der 
Moglichkeit, irreversible Zahlungen fur irreversible Dienstleistungen zu tatigen. Durch die Option, 
Transaktionen riickgangig zu machen, erhoht sich das notwendige Vertrauen. Handler miissen ihren Kunden 
gegeniiber misstrauisch sein und von ihnen mehr Infonnationen verlangen, als ansonsten notwendig waren. Ein 
bestimmtes MaB an Betrug wird als unvermeidbar akzeptiert. Diese Kosten und Zahlungsunsicherheiten konnen 
durch personlichen Kontakt und die Verwendung einer physischen Wahrung vermieden werden, doch es existiert 
kein Mechanismus fur die Leistung von Zahlungen iiber einen Kommunikationskanal ohne eine 
vertrauenswiirdige Partei. 

Notwendig ist ein elektronisches Zahlsystem, das auf kryptographischem Nachweis an Stelle von Vertrauen 
basiert und es zwei bereitwilligen Parteien ermoglicht, Transaktionen direkt untereinander durchzufuhren, ohne 
dass eine vertrauenswiirdige dritte Partei benotigt wird. Transaktionen, bei denen es rechnerisch unmoglich ist, sie 
zu widerrufen, wiirden die Verkaufer vor Betrug schiitzen, und standardisierte Treuhandmechanismen kdnnten auf 
einfache Weise implementiert werden, um die Kiiufer zu schiitzen. In diesem Paper schlagen wir eine Losung fiir 
das Double-Spending-Problem vor, die unter Verwendung eines verteilten Peer-to-Peer-Zeitstempel-Servers einen 
rechnerischen Nachweis der chronologischen Reihenfolge der Transaktionen erzeugt. Das System ist sicher, 
solange die ehrlichen Nodes mehr CPU-Leistung kontrollieren als jede kooperierende Gruppe von angreifenden 
Nodes. 
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2. Transaktionen 


Wir defmieren eine elektronische Miinze (Coin) als eine Kette digitaler Signaturen. Jeder Eigentiimer iibertragt 
den Coin auf den nachsten, indem er einen Hash der vorherigen Transaktion sowie den offentlichen Schliissel des 
nachsten Eigentiimers digital signiert und dies an das Ende des Coins anhangt. Der Empfanger der Zahlung kann 
die Signaturen verifizieren, um die Kette der Eigentiimer zu verifizieren. 



Das Problem ist natiirlich, dass der Zahlungsempfanger nicht verifizieren kann, dass einer der Eigentiimer den 
Coin nicht doppelt ausgegeben hat. Eine gebrauchliche Losung ist, eine zentrale, vertrauenswiirdige Instanz, oder 
Miinzanstalt, einzuflihren, die jede Transaktion auf Double Spending (Mehrfachausgabe) priift. Nach jeder 
Transaktion muss der Coin an die Miinzanstalt zuriickgegeben werden, damit diese einen neuen Coin herausgibt, 
und nur bei Coins, die direkt von der Miinzanstalt ausgegeben wurden, kann darauf vertraut werden, dass sie nicht 
doppelt ausgegeben worden sind. Das Problem mit dieser Losung ist, dass das Schicksal des gesamten 
Geldsystems von dem Untemehmen abhangt, das die Miinzanstalt betreibt, und dass jede Transaktion iiber dieses 
laufen muss, wie bei einer Bank. 

Wir brauchen eine Methode, um Gewissheit fiir den Zahlungsempfanger zu schaffen, dass die vorherigen 
Eigentiimer keine friiheren Transaktionen signiert haben. Fiir unsere Zwecke ist die erste Transaktion diejenige, 
die zahlt, so dass wir uns keine Sorgen iiber spatere Versuche zur Mehrfachausgabe machen miissen. Die einzige 
Moglichkeit, die Abwesenheit einer Transaktion zu bestatigen, ist es, alle Transaktionen zu kennen. In dem auf 
einer Miinzanstalt basierenden Modell kannte die Miinzanstalt alle Transaktionen und konnte entscheiden, welche 
zuerst eingetroffen ist. Um dies ohne vertrauenswiirdige Partei zu erreichen, miissen Transaktionen offentlich 
gemacht werden [1], und wir benotigen ein System, mit dem sich die Teilnehmer auf einen einzigen Verlauf der 
Reihenfolge, in der sie eingetroffen sind, einigen. Der Zahlungsempfanger benotigt einen Nachweis, dass sich 
zum Zeitpunkt jeder Transaktion die Mehrheit der Knoten des Netzwerks einig sind, dass sie diese zuerst 
empfangen haben. 

3. Zeitstempel-Server 

Die von uns vorgeschlagene Losung beginnt mit einem Zeitstempel-Server. Ein Zeitstempel-Server funktioniert, 
indem er den Hash eines Blocks von mit Zeitstempel zu versehenden Datensatzen nimmt und den Hash 
weitlaufig, etwa in einer Zeitung oder in einem Usenet-Post, veroffentlicht [2-5], Der Zeitstempel beweist, dass 
die Daten zu diesem Zeitpunkt existiert haben, offensichtlich, denn sonst gabe es keinen Hash von ihnen. Jeder 
Zeitstempel beinhaltet in seinem Hash den vorhergegangenen Zeitstempel und bildet eine Kette, bei der jeder 
zusatzliche Zeitstempel die vorherigen verstarkt. 
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4. Proof-of-Work 

Um einen verteilten Zeitstempel-Server auf Peer-to-Peer-Basis zu implementieren, miissen wir ein Proof-of- 
Work-System, ahnlich des Hashcash-Systems von Adam Back [6], anstatt der Zeitungen oder Usenet-Posts 
verwenden. Der Proof-of-Work beinhaltet die Suche nach einem Wert, bei dem, wenn er gehasht wird, etwa durch 
SHA-256, der Hash mit einer Anzahl von Nullbits beginnt. Die durchschnittlich erforderliche Arbeit ist 
exponentiell zu der Anzahl der erforderlichen Nullbits und kann durch die Ausfuhrung eines einzelnen Hashs 
verifiziert werden. 

Fur unser Zeitstempel-Netzwerk implementieren wir den Proof-of-Work, indem eine Nonce im Block solange 
ansteigt, bis ein Wert gefunden wird, der dem Hash des Blocks die erforderlichen Nullbits gibt. Nachdem die 
CPU geniigend Arbeit aufgewendet hat, um den Proof-of-Work zu erfullen, kann der Block nicht mehr geandert 
werden, ohne dass die Arbeit erneut ausgefiihrt wird. Da spatere Blocks damit verkettet werden, wiirde die Arbeit 
zur Anderung des Blocks die Neuerstellung aller nachfolgenden Blocks beinhalten. 
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Der Proof-of-Work lost auBerdem das Problem, bei Mehrheitsentscheidungen die Reprasentanten zu 
bestimmen. Wenn die Mehrheit auf einer Stimme je IP-Adresse basieren wiirde, konnte diese durch jeden 
unterwandert werden, der in der Lage ist, viele IPs zu reservieren. Proof-of-Work ist im Grunde eine Stimme pro 
CPU. Die Mehrheitsentscheidung wird durch die langste Kette reprasentiert, in die der groBte Proof-of-Work 
Aufwand investiert wurde. Wenn eine Mehrheit der CPU-Leistung von ehrlichen Rnoten kontrolliert wird, wird 
die ehrliche Kette am schnellsten wachsen und alle konkurrierenden Ketten abhangen. Um einen vergangenen 
Block zu andem, miisste ein Angreifer den Proof-of-Work des Blocks sowie den aller nachfolgenden Blocks neu 
erzeugen, und dann die ehrlichen Nodes einholen und iiberholen. Wir werden spater demonstrieren, dass die 
Moglichkeit, dass ein langsamerer Angreifer aufholt, sich exponentiell verringert, je mehr nachfolgende Blocke 
hinzugefugt werden. 

Um steigende Hardwareleistung und zeitlich schwankendes Interesse, einen arbeitenden Node zu betreiben, 
auszugleichen, wird die Proof-of-Work-Schwierigkeit durch einen gleitenden Mittelwert bestimmt, der eine 
durchschnittliche Anzahl von Blocks pro Stunde anpeilt. Wenn sie zu schnell generiert werden, steigt die 
Schwierigkeit. 

5. Netzwerk 

Die Schritte zum Betrieb des Netzwerks sind die Folgenden: 

1) Neue Transaktionen werden an alle Rnoten ausgestrahlt. 

2) Jeder Rnoten sammelt die neuen Transaktionen in einem Block. 

3) Jeder Rnoten arbeitet daran, einen schwierigen Proof-of-Work fur seinen Block zu finden. 

4) Wenn ein Rnoten einen Proof-of-Work findet, strahlt er den Block an alle Rnoten aus. 

5) Die Rnoten akzeptieren den Block nur, wenn alle Transaktionen darin giiltig und nicht bereits 
ausgegeben sind. 

6) Die Rnoten driicken ihre Akzeptanz des Blocks aus, indem sie daran arbeiten, den nachsten Block in der 
Kette zu erzeugen, wofur sie die Hash des akzeptierten Blocks als vorhergegangene Hash verwenden. 

Rnoten gehen immer davon aus, dass die langste Kette die korrekte ist und arbeiten daran, diese zu 
verlangem. Wenn zwei Rnoten gleichzeitig verschiedene Versionen des nachsten Blocks iibertragen, konnten 
einige Nodes die eine oder die andere Version zuerst empfangen. In diesem Fall arbeiten sie an der ersten, die sie 
empfangen haben, speichem aber den anderen Zweig fur den Fall, dass dieser langer wird. Der Gleichstand wird 
gebrochen, wenn der nachste Proof-of-Work gefunden wird und ein Zweig langer wird; die Nodes, die am 
anderen Zweig gearbeitet haben, werden dann auf den langeren umschalten. 

Die Ausstrahlung neuer Transaktionen muss nicht zwingend jeden Rnoten erreichen. So lange sie viele 
Rnoten erreichen, werden sie friiher oder spater in einem Block aufgenommen. Blockausstrahlungen sind auch 
tolerant gegeniiber verlorenen Nachrichten. Wenn ein Rnoten einen Block nicht empfangt, wird er diesen 
anfordem, sobald er den nachsten Block empfangt und erkennt, dass ihm einer fehlt. 
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6. Anreize 


Durch Konvention ist die erste Transaktion in einem Block eine spezielle Transaktion, die einen neuen Coin 
schopft, der dem Erzeuger des Blocks gehort. Dies gibt neuen Knoten einen Anreiz, das Netzwerk zu 
unterstiitzen, und bietet einen Weg, Miinzen erstmals in Umlauf zu bringen, da es keine zentrale Instanz gibt, die 
sie herausgibt. Das standige Hinzufugen einer konstanten Anzahl neuer Coins ist analog zu Goldgrabem, die 
Ressourcen aufwenden, um mehr Gold in Umlauf zu bringen. In unserem Falle sind es CPU-Zeit und Elektrizitat, 
die aufgewendet werden. 

Die Anreize konnen auch durch Transaktionsgebiihren gefordert werden. Wenn der Ausgangswert der 
Transaktion geringer ist als ihr Eingangswert, entspricht der Unterschied einer Transaktionsgebiihr, die dem Wert 
des Anreizes des Blocks hinzugefugt wird, der die Transaktion enthalt. Wenn einmal eine vorherbestimmte 
Anzahl von Coins in Umlauf gebracht wurde, konnen die Anreize vollstandig auf Transaktionsgebiihren 
iibergehen und so vollstandig inflationsfrei sein. 

Die Anreize konnen helfen, Knoten zu motivieren, ehrlich zu bleiben. Wenn ein gieriger Angreifer in der Lage 
ist, mehr CPU-Leistung aufzubringen als alle ehrlichen Nodes, miisste er wahlen, ob er diese Leistung verwendet, 
um Menschen zu betriigen, indem er seine Zahlungen zuriick stiehlt, oder ob er sie nutzt, um neue Coins zu 
erzeugen. Er sollte es profitabler fmden, sich an die Regeln zu halten - Regeln, die ihn mit mehr neuen Coins 
versorgen konnen als alle anderen zusammen - als dass er das System und damit die Giiltigkeit seines eigenen 
Wohlstands untergrabt. 

7. Speicherplatz zuruck gewinnen 

Sobald die letzte Transaktion eines Coins unter ausreichend Blocken begraben ist, konnen die verbrauchten 
Transaktionen davor geloscht werden, um Speicherplatz zu sparen. Um dies zu ermdglichen, ohne den Hash des 
Blocks zu brechen, werden die Transaktionen in einem Merkle-Tree [7] [2] [5] gehasht, und lediglich die Root in 
die Hash des Blocks aufgenommen. Alte Blocke konnen dann komprimiert werden, indem Zweige des Baumes 
gekappt werden. Die intemen Hashes miissen nicht gespeichert werden. 



Transactions Hashed in a MerkleTree 



After Pruning Tx0-2from the Block 


Ein Blockheader ohne Transaktionen benotigt etwa 80 Byte. Wenn wir davon ausgehen, dass Blocke alle 10 
Minuten generiert werden, entsprechen 80 Byte * 6 * 24 * 365 = 4,2 MB pro Jahr. Mit Computersystemen, die im 
Jahr (Stand 2008) typischerweise mit 2 GB RAM verkauft werden, und Moores Law, das aktuell ein Wachstum 
von 1,2 GB prognostiziert, sollte Speicherplatz kein Problem darstellen, selbst wenn die Blockheader im Speicher 
gehalten werden miissen. 
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8. Vereinfachte Zahlungs verifizierung 

Es ist moglich Zahlungen zu verifizieren, ohne einen kompletten Netzwerk-Node zu betreiben. Ein Nutzer muss 
lediglich eine Kopie der Blockheader der langsten Proof-of-Work-Kette aufbewahren, die er erhalten kann, indem 
er andere Netzwerk-Knoten solange abfragt, bis er uberzeugt ist, dass er die langste Kette hat, und den Merkle- 
Zweig beziehen, der die Transaktion mit dem Block verkniipft, durch den sie einen Zeitstempel erhalten hat. Er 
kann die Transaktion nicht selbst priifen, aber indem er sie mit einer Stelle in der Kette verkniipft, kann er sehen, 
dass sie von einem Netzwerk-Node akzeptiert wurde, und Blocke, die danach angefugt wurden, bestatigen weiter, 
dass sie vom Netzwerk akzeptiert wurde. 


Longest Proof-of-Work Chain 



Als solche ist die Verifizierung zuverlassig, solange das Netzwerk von ehrlichen Nodes kontrolliert wird. Sie 
wird aber angreifbarer, wenn das Netzwerk von einem Angreifer iiberwaltigt wird. Wahrend Netzwerk-Knoten 
Transaktionen selbst verifizieren konnen, kann die vereinfachte Methode so lange durch einen Angreifer mit 
fingierten Transaktionen getauscht werden, wie der Angreifer das Netzwerk dominieren kann. Eine Strategic, sich 
dagegen zu schutzen, ware es, Alarmsignale von Netzwerk-Nodes zu akzeptieren, wenn diese einen ungiiltigen 
Block erkennen, was die Software des Users veranlassen wurde, den vollen Block und die vom Alarm 
betroffenen Transaktionen herunterzuladen, um die Inkonsistenz zu bestatigen. Untemehmen, die regelmaBige 
Zahlungen erhalten, werden dennoch ihre eigenen Nodes betreiben wollen, fur eine unabhangigere Sicherheit und 
schnellere Verifizierung. 

9. Zusammenfuhrung und Aufteilung von Werten 

Obgleich es moglich ware, die Coins einzeln zu handhaben, ware es unpraktisch, fur jeden Cent in einem Transfer 
eine separate Transaktion durchzufuhren. Damit Werte aufgeteilt und zusammengefLihrt werden konnen, enthalten 
Transaktionen mehrere Inputs und Outputs. Normalerweise gibt es entweder einen einzelnen Inputs von einer 
groBeren vorausgegangenen Transaktion oder mehrere Inputs, die kleinere Betrage zusammenfassen, und 
hochstens zwei Ausgange: einer fur die Zahlung und einer flir die Riickgabe von Wechselgeld, falls notwendig, 
zuriick an den Absender. 



Es sollte erwahnt werden, dass eine Auffacherung, bei der eine Transaktion von mehreren Transaktionen 
abhangig ist, und diese Transaktionen wiederum von vielen anderen abhangen, in diesem Fall kein Problem 
darstellt. Es besteht niemals die Notwendigkeit, eine vollstandige Kopie eines Transaktionsverlaufs abzurufen. 
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10. Datenschutz 


Das traditionelle Bankenmodell erreicht ein bestimmtes Datenschutzniveau, indem der Zugriff auf die 
Informationen auf die beteiligten Parteien und die vertrauenswiirdige dritte Partei begrenzt wird. Die 
Notwendigkeit, alle Transaktionen zu veroffentlichen, schlieBt diese Methode aus, aber der Datenschutz kann 
dennoch aufrecht erhalten werden, indem der Informationsfluss an einer anderen Stelle unterbrochen wird: indem 
die offentlichen Schliissel anonym bleiben. Die Offentlichkeit kann sehen, dass jemand einen Betrag an jemand 
anderen sendet, aber ohne Informationen, die die Transaktionen mit irgendjemandem verkniipfen. Das ist dem 
Level an Informationen ahnlich, das von Aktienborsen veroffentlicht wird, bei dem die Zeit und die GroBe der 
individuellen Handelsvorgange, das "Tape", veroffentlicht wird, ohne dass dabei gesagt wird, wer die Parteien 
sind. 



New Privacy Model 



Als zusatzliche Firewall sollte fur jede Transaktion ein neues Schliisselpaar verwendet werden, um zu 
vermeiden, dass die Schliissel einem gemeinsamen Eigentiimer zugeordnet werden konnen. Manche 
Verkniipfungen sind bei Transaktionen mit mehreren Eingangen noch immer unvermeidbar, weil diese 
notwendigerweise preisgeben, dass ihre Eingange zum gleichen Eigentiimer gehoren. Das Risiko besteht darin, 
dass, wenn der Eigentiimer eines Schliissels bekanntgegeben wird, die Verkniipfung weitere Transaktionen 
offenlegen konnte, die zum gleichen Eigentiimer gehort haben. 


11. Berechnungen 

Wir ziehen ein Szenario in Betracht, bei dem ein Angreifer versucht, eine alternative Kette schneller zu erzeugen 
als die ehrliche Kette. Selbst wenn dies gelingt, setzt es das System nicht willkiirlichen Anderungen aus, wie zum 
Beispiel die Erzeugung von Wert aus dem Nichts oder das Nehmen von Geld, das dem Angreifer nicht gehort. 
Die Nodes werden keine ungiiltige Transaktion als Zahlung akzeptieren, und die ehrlichen Nodes werden niemals 
einen Block akzeptieren, der eine solche enthalt. Ein Angreifer kann lediglich versuchen, eine seiner eigenen 
Transaktionen zu verandem, um Geld zuriick zu bekommen, das er vor kurzem ausgegeben hat. 

Das Rennen zwischen einer ehrlichen Kette und der Kette eines Angreifers kann als Binomischer Random 
Walk charakterisiert werden. Das Erfolgsereignis ist, dass die ehrliche Kette um einen Block erweitert wird, was 
deren Vorsprung um +1 erhoht, und das Scheitem ist, dass die Kette des Angreifers um einen Block erweitert 
wird, was den Abstand um -1 reduziert. 

Die Wahrscheinlichkeit, dass ein Angreifer aus einem gegebenen Riickstand aufholt, ist analog zum Problem 
des "Ruin des Spielers". Angenommen, ein Spieler mit unbegrenztem Kredit beginnt mit einem Riickstand und 
spielt potentiell eine unbegrenzte Anzahl von Partien, mit dem Ziel, die Gewinnschwelle zu erreichen. Wir 
konnen die Wahrscheinlichkeit, dass er jemals die Gewinnschwelle erreicht, oder dass ein Angreifer jemals eine 
ehrliche Kette einholt, wie folgt berechnen [8]: 

p = Wahrscheinlichkeit, dass ein ehrlicher Node den nachsten Block fmdet 

q = Wahrscheinlichkeit, dass der Angreifer den nachsten Block fmdet 

q-_ = Wahrscheinlichkeit, dass der Angreifer jemals den Riickstand von z Blocken aufholt 


i if p^q\ 
{(q'pY if p >c i J 


Unter unserer Annahme, dass p > q, fallt die Wahrscheinlichkeit exponentiell, wenn die Anzahl der Blocks, die 
der Angreifer aufholen muss, steigt. Wenn die Wahrscheinlichkeit gegen ihn ist und er nicht friihzeitig einen 
gliicklichen Sprung vorwarts macht, werden seine Chancen verschwindend gering, wenn er weiter zuriick fallt. 

Wir erortern nun, wie lange der Empfanger einer neuen Transaktion warten muss, bis er ausreichend sicher ist, 
dass der Absender die Transaktion nicht mehr andem kann. Wir nehmen an, dass der Absender ein Angreifer ist, 
der den Empfanger fur eine Weile glauben lassen mochte, dass er bezahlt wurde, und dann die Transaktion nach 
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einiger Zeit verandert, so dass sie an ihn selbst zuriickgezahlt wird. Der Empfanger wird alarmiert, wenn dies 
geschieht, aber der Absender hofft, dass es dann zu spat ist. 

Der Empfanger generiert ein neues Schliisselpaar und gibt den Public Key kurz vor dem Signieren an den 
Sender. Dies verhindem, dass der Sender bereits im Voraus eine Kette von Blocks vorbereitet, indem er so lange 
daran arbeitet, bis er ausreichend Gluck gehabt hat, um einen ausreichend groBen Vorsprung zu haben, und dann 
die Transaktion in diesem Moment ausfuhrt. Wenn die Transaktion einmal abgeschickt wurde, beginnt der 
unehrliche Sender insgeheim mit der Arbeit an einer parallelen Kette, die eine geanderte Version seiner 
Transaktion enthalt. 

Der Empfanger wartet, bis die Transaktion zu einem Block hinzugefiigt wurde und z Blocks dahinter angefligt 
wurden. Er weiB nicht genau, welchen Fortschritt der Angreifer bereits gemacht hat, aber davon ausgehend, dass 
die ehrlichen Blocks die durchschnittliche Zeit pro Block benotigt haben, entspricht der potentielle Fortschritt des 
Angreifers einer Poisson-Verteilung mit dem erwarteten Wert: 


A=2 


1 

P 


Um die Wahrscheinlichkeit zu berechnen, dass der Angreifer jetzt noch aufholen konnte, multiplizieren wir die 
Poisson-Dichte fur jede Summe des Fortschritts, den er gemacht haben konnte, mit der Wahrscheinlichkeit, dass 
er von diesem Punkt an aufholen konnte: 

x - A* g A \{ql p)' z ~ k ' ifk<z\ 
k\ '[ 1 ifk>z\ 

Wir stellen die Formel um, um zu vermeiden, dass die unendlichen Nachkommastellen der Verteilung addiert 
werden... 


A=0 *• 


Und ubersetzen dies in C Code... 

tinclude <math.h> 

double AttackerSuccessProbability(double q, int z) 

{ 

double p = 1.0 - q; 

double lambda = z * (q / p); double sum = 1.0; 
int i, k; 

for (k = 0; k <= z; k++) 

{ 

double poisson = exp(-lambda); for (i = 1; i <= k; i++) 
poisson *= lambda / i; 

sum -= poisson * (1 - pow(q / p, z - k)); 

} 

return sum; 


Wenn wir einige Ergebnisse durchlaufen lassen, konnen wir erkennen wie die Wahrscheinlichkeit exponentiell mit 
z abfallt. 

q=0.1 

z=0 P=l.0000000 
z=l P=0,2045873 
z=2 P=0,0509779 

z=3 P=0,0131722 

z=4 P=0,0034552 

z=5 P=0,0009137 

z=6 P=0,0002428 

z=7 P=0,0000647 

z=8 P=0,0000173 

z=9 P=0,0000046 

z=10 P=0,0000012 

q=0,3 

z=0 P=l.0000000 
z=5 P=0.1773523 
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z=10 P=0.0416605 

z=15 P=0.0101008 

z=20 P=0.0024804 

z=25 P=0.0006132 

z=30 P=0.0001522 

z=35 P=0.0000379 

z=40 P=0.0000095 

z=45 P=0.0000024 

z=50 P=0.0000006 

Auflosung fiir P kleiner als 0,1% ... 

P < 0.001 
q=0.10 z=5 
q=0.15 z=8 
q=0.20 z=ll 
q=0.25 z=15 
q=0.30 z=24 
q=0.35 Z—41 
q=0.40 z=89 
q=0.45 z=340 


12. Fazit 

Wir haben ein System fur elektronische Transaktionen vorgeschlagen, ohne uns auf Vertrauen zu stiitzen. Wir sind 
vom iiblichen System von aus digitalen Signaturen erstellten Coins ausgegangen, das eine starke Kontrolle iiber 
die Eigentiimerschaft bietet, aber unvollstandig ist ohne eine Methode, um Mehrfachausgaben zu verhindem. Um 
dieses Problem zu losen, haben wir ein Peer-to-Peer-Netzwerk vorgeschlagen, das Arbeitsbeweise benutzt, um 
eine offentliche Historic von Transaktionen aufzuzeichnen, die fur einen Angreifer rasch unmoglich veranderbar 
sind, solange ehrliche Nodes die Mehrheit der CPU-Leistung kontrollieren. Das Netzwerk ist in seiner 
unstrukturierten Einfachheit robust. Die Nodes arbeiten alle zur gleichen Zeit mit nur wenig Koordination. Sie 
miissen nicht identifiziert werden, da die Nachrichten nicht zu einer bestimmten Stelle geleitet werden und nur 
auf Basis der besten Bemiihungen ausgeliefert werden miissen. Knoten konnen das Netzwerk nach Belieben 
verlassen bzw. diesem beitreten und den Proof-of-Work als Nachweis dafiir akzeptieren, was wahrend ihrer 
Abwesenheit geschehen ist. Sie stimmen mit ihrer CPU-Leistung ab, driicken ihre Akzeptanz von zulassigen 
Blocks dadurch aus, dass sie an deren Erweiterung arbeiten und weisen ungiiltige Blocks dadurch ab, dass sie sich 
weigem, an diesen zu arbeiten. Alle erforderlichen Regeln und Anreize konnen mit Hilfe dieses 
Konsensmechanismus durchgesetzt werden. 



Referenzen 

[1] W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998. 

[2] H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust 
requirements," In 20th Symposium on Information Theory in the Benelux, May 1999. 

[3] S. Haber, W.S. Stometta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no 2, 
pages 99-111, 1991. 

[4] D. Bayer, S. Haber, W.S. Stometta, "Improving the efficiency and reliability of digital time-stamping," In 
Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993. 

[5] S. Haber, W.S. Stometta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference on 
Computer and Communications Security, pages 28-35, April 1997. 

[6] A. Back, "Hashcash - a denial of service counter-measure," http://www.hashcash.org/papers/hashcash.pdf, 

2002 . 

[7] R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and Privacy, 
IEEE Computer Society, pages 122-133, April 1980. 

[8] W. Feller, "An introduction to probability theory and its applications," 1957. 


9 



